As computer technology has advanced, the richness and complexity of computer graphics has also steadily increased. Early animations were typically static files that transformed the physical animation paradigm, used in early film animation, to the electronic world. Multiple layers (i.e., cells) of static frames are displayed in quick succession giving the illusion of motion and, thus, animation. In the physical world, individual frame transparencies on cellulose or some other such material were typically flipped on top of one another creating a layering that visually provided the appearance of motion. In the electronic world, the computer display essentially mimics this process by sequentially rendering each frame in order, again, giving the illusion of motion.
Traditionally, each animation space, the physical and electronic, generally use timelines to manage and control the animation. In the physical world, such timelines are often summarized into storyboards, which set the timing of when the animation should display a certain set of subjects or key frames and the state in which each such subject should be. In the electronic world, the timeline generally sets the overall chronological progression for each frame rendering including each object within each frame. A timer mechanism, coupled with a parameter that controls how many frames are to be displayed per time unit, usually work together to control the progress of any given electronic animation. Electronic animations have typically been created and placed as static files onto Web pages or a CD-ROM or other similar storage media. Because the animations are run according to the timeline, animation content is usually static. For example, the subject of the animation may start at point A and travel to point B over a set path. All three such parameters are typically known and set from the creation of the animation. The developer usually sets point A, sets point B, and determines the path that will be used to move from point A to point B. Alternatively, the developer will set point A, determine a path, and then allow the path or time progression to determine the end point, point B. This information is hard-coded onto a file that is accessible through a Web server, a type of physical storage media, such as a CD-ROM, or the like.
As the Internet has become more of an interactive business source, Web pages and Websites have become more dynamic. Application servers generally use an application server language and scripting language, such as MACROMEDIA INC.'s COLDFUSION™ MARKUP LANGUAGE (CFML), MICROSOFT CORPORATION's ACTIVE SERVER PAGES™ (ASP & ASP.NET™) and C#™ or VISUAL BASIC™ (VB) scripting languages, SUN MICROSYSTEMS, INC.'s JAVA™ SERVER PAGES (JSP) and JAVA™ scripting language, the open source standard Common Gateway Interface (CGI) and Practical Extraction and Reporting Language (PERL) scripting language, and the like. The code for the application server language typically resides on the Web server or application server. When it is called by a client, the code executes and usually performs some kind of calculation or gathers some kind of data from an external source, such as a database or the like, and then assembles all of the processed and/or retrieved information into an HTML file formatted according to the instructions in the application server logic and then transmitted to the requesting client's Web browser. The processed/retrieved information will then be presented to the user on the Web browser at the requesting client in a manner that was determined by the programmer of the application server language.
In the interactive world of application servers and application server languages, the final appearance of any Web page generated by one of these technologies is usually not set until the processing and/or retrieving of the information has been completed. This may not even be completed until the user interacts with some HTML form or other kind of interactive user interface to provide additional information. An example of such a system would be an airline reservation system. The general look and style of the resulting Web page will have a consistent feel; however, the final appearance, with any search results or reservation results will not be set until the user interacts with the backend logic of the airline system. Not only is the final appearance of the Web page not set by the time the application server or behind-the-scenes logic is made available to the public, it will not be set until the user has entered the flight information or request for flight information. Without the pre-knowledge of the various objects that will eventually be displayed on any given generated Web page, it is difficult to provide animations of these arbitrary and unknown objects.
Because animation can be an effective tool for enhancing the user experience in any interactive Web application, techniques were developed to overcome this shortcoming in implementing animated graphics on dynamic Web applications. Even though designing animations is much simpler using the timeline-based systems, such as MACROMEDIA FLASH™ and DIRECTOR™, such development environments could not easily be used by the graphical designers to create conditional animations of unknown items. Instead, experienced programmers code complicated logic that explicitly describes how any animations of such unknown objects would occur on the Web page. Taking the examples of FLASH™ and DIRECTOR™, after a designer creates the graphics associated with the animation or interactive media, experienced programmers code complicated and explicit blocks in ACTIONSCRIPT™, the scripting language from MACROMEDIA, INC., that is native to FLASH™, or LINGO™, the scripting language from MACROMEDIA, INC., that is native to DIRECTOR™, that handle any animation of arbitrary screen objects.
Code developers typically write the explicit code that examines such objects and then express how those objects would be moved around the display canvas. Alternatively, the code developers would employ a more object-oriented approach that defines the object classes and describes how instances of such objects would behave and/or move in various situations. Either of these coding techniques allows developers to provide animation of arbitrary display objects that are known only at or during runtime. However, experienced programmers are used to create this animation capability. This adds a layer of complexity to animation that was previously not necessary.
In the last few years, Web interaction is slowly evolving to include more Rich Internet Applications (RIAs). RIAs provide rich graphical and interactive applications over the Internet which perform a portion of the logic calculation and processing on the client's computer. Unlike the thin-client paradigm of the current client-server architecture, in which all of the processing is typically done on the server with only the resulting static HTML page transmitted to the client, rich-client systems perform much of the calculation and processing on the client computer. Processing such as field validation, data formatting, sorting, filtering, tool tips, integrated video, behaviors, effects, and the like, which are better suited for client-side processing are moved to the client. This typically provides a much more satisfying user experience, in that certain processing and transitions occur much faster than if the user would have to wait for a server request and response with a new finished page for each application interaction.
In application, many RIA are implemented using interactive multimedia files that that are executed on a compatible player on the client computer. The interactive multimedia runtime containers (iMRC), which are the interactive multimedia files running on the media player, operate the user interface and underlying logic. The iMRC may also have a facility to communicate with a remote communication server to supplement the execution of the application. One example of an iMRC is an instance of a FLASH™ player running a SWF file. The native FLASH™ player file, the SWF file format, is downloaded to the client computer and runs on the FLASH™ player either standing alone or on top of the client's Web browser. FLASH™ allows considerable interactivity with the user and has facility to communicate with a FLASH™ COMMUNICATION SERVER (FCS) or MACROMEDIA INC.'s FLEX™ presentation server to supplement the FLASH™ RIA operation.
In RIAs, because many applications include animations as a part of the logic presentation, substantial coding is typically used to provide for the animation of objects that have an unknown existence and position at design time. Many parts of the RIA may be created by designers using timeline-based development environments. However, in order to implement the conditional animations, an experienced programmer is generally used to complete the application. This divided creation process adds a layer of complexity to the design and generally prohibits RIA development by pure design-oriented individuals.
In development environments suitable to generate RLAs, such as the FLASH™ development environment and MACROMEDIA INC.'s FLEX BUILDER™, there are generally three main divisions of the overall architecture: the tool, the framework, and the runtime. The tool is the user interface that the designer/developer interacts with to build the application. A framework, in general, is a set of classes, components, and the like that are specifically provided for the functionality of the development environment. The framework may contain many pre-built, useful components, such as windows, menus, and the like, along with defined events that can be used in assembling a completed application without the need to code everything from scratch. The runtime is the operational container that runs the executable file that results from compiling the application and framework. Conceptually, the framework runs on top of the runtime, while the application runs on top of the framework.
In existing systems, the framework is generally tied in with the tool. Thus, the developer creates the application using the tool and then compiles the application, which uses the framework, to produce the executable that is to be delivered as the RIA. The compiled file will sit at an accessible location until called by an accessing user. The user will have a runtime container on his or her computer that will play the executable file and execute the RIA. When creating an animation, the tool is used to define the motion path. The tool gives the motion path, which is defined according to the classes and event of the framework, to the framework to produce the final instructions for the motion path. The final instructions instruct the runtime how to render all of the pieces of the animation in executing the RIA. This architecture results in the instructions for the motion path being finalized at the tool, because the current systems have the framework tied in with the tool. Therefore, it is difficult to design an application that includes conditional animations.